Add picks variable selection to ae_oview module#331
Conversation
|
I have read the CLA Document and I hereby sign the CLA osenan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
|
I have read the CLA Document and I hereby sign the CLA |
|
Changed to draft as I need to fix:
|
There was a problem hiding this comment.
Some preliminary comments.
- I believe this is a good case for only keeping 1 version of the module logic. (We can convert directly from
choices_selected->variables()) - I see that you're using
picks(), consider usingvariables()instead forarm_varandflag_var_anl- And then create
picks()inside thetm_g_ae_oview()call
- And then create
R/tm_g_ae_oview.R
Outdated
| arm_var = teal.picks::picks( | ||
| teal.picks::datasets(), | ||
| teal.picks::variables( | ||
| choices = teal.picks::is_categorical(min.len = 2), | ||
| selected = 1L | ||
| ) | ||
| ), | ||
| flag_var_anl = teal.picks::picks( | ||
| teal.picks::datasets(), | ||
| teal.picks::variables( | ||
| choices = teal.picks::is_categorical(min.len = 2), | ||
| selected = 1L | ||
| ) | ||
| ), |
There was a problem hiding this comment.
I think this is a good candidate to use variables() in the arguments:
| arm_var = teal.picks::picks( | |
| teal.picks::datasets(), | |
| teal.picks::variables( | |
| choices = teal.picks::is_categorical(min.len = 2), | |
| selected = 1L | |
| ) | |
| ), | |
| flag_var_anl = teal.picks::picks( | |
| teal.picks::datasets(), | |
| teal.picks::variables( | |
| choices = teal.picks::is_categorical(min.len = 2), | |
| selected = 1L | |
| ) | |
| ), | |
| arm_var = teal.picks::variables( | |
| choices = teal.picks::is_categorical(min.len = 2), | |
| selected = 1L | |
| ), | |
| flag_var_anl = teal.picks::variables( | |
| choices = teal.picks::is_categorical(min.len = 2), | |
| selected = 1L | |
| ), |
You can then overwrite arguments with picks() in tm_g_ae_oview.variables (and use dataname):
# ...
arm_var <- teal.picks::picks(datasets(dataname), arm_var)
flag_var_anl <- teal.picks::picks(datasets(dataname), flag_var_anl)There was a problem hiding this comment.
Changed, actually it is simpler good idea
| selectInput( | ||
| ns("arm_ref"), | ||
| "Control", | ||
| choices = NULL | ||
| ), | ||
| selectInput( | ||
| ns("arm_trt"), | ||
| "Treatment", | ||
| choices = NULL | ||
| ), |
There was a problem hiding this comment.
Interesting case here as we have dependent input fields from arm_var = picks(...).
Should these be created independently reusing arm_var datasets & variables
- that is: having 2 picks
- this will create problems downstream though
Or [possible feature]
Is this a case for having multiple values() in a picks, which generate multiple selectors.
picsk(datasets("ADAE"), variables(), values(), values()) # with some way to differentiate between control and treatement@gogonzo maybe this is one of the cases of bookmark manager we remember.
There was a problem hiding this comment.
I think this is related to this issue: insightsengineering/teal.picks#14.
My initial plan was to go for the second option. But it is hard to distinguish here what is what: should picks(datasets("ADAE"), variables(), values(), values()) join all the values in a single selection or not? To disambiguate I thought about using operators: picks(datasets("ADAE"), variables()) + values() | values(): a picks with two options/selectors.
Currently I think it is better if we create a function to handle those cases.
There was a problem hiding this comment.
Let's solve the issue and then update this module
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
|
I have read the CLA Document and I hereby sign the CLA |
|
The plot and decorator I will handle in a separate issue finally |
Code Coverage SummaryDiff against mainResults for commit: 5f0cfc2 Minimum allowed coverage is ♻️ This comment has been updated with latest results |
Unit Tests Summary 1 files 2 suites 0s ⏱️ Results for commit 5f0cfc2. ♻️ This comment has been updated with latest results. |
Unit Test Performance Difference
Additional test case details
Results for commit 8195974 ♻️ This comment has been updated with latest results. |
|
Now the example should be tested with this app: |
averissimo
left a comment
There was a problem hiding this comment.
Awesome! It works great and it even supports picks conversion for choices_selected
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
Co-authored-by: André Veríssimo <211358+averissimo@users.noreply.github.com> Signed-off-by: Oriol Senan <35930244+osenan@users.noreply.github.com>
Pull Request
This partially closes #330
I based my changes in this PR.
Please compare both modules with this example app (requires to have teal.picks installed, osprey)
I refactored the
tm_g_ae_oviewmodule to create a generic, keep the default forteal.transformand add a method for picks variable selection. The module works as expected and setting the variables is better with picks. The issue reported in the similar PR on the plot dimensions is fixed if we set the plot dimensions in the module. The ui of the picks ui components is different and it breaks, in my opinion, the color pattern of the teal app.Here the teal.transform module
I added simple tests for the module as well